added test if messurement of BME280Sensor was successfull fixes #11301 - #11302
added test if messurement of BME280Sensor was successfull fixes #11301#11302mcenderdragon wants to merge 3 commits into
Conversation
|
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughBME280 initialization sets a 50 ms I2C timeout and forced-mode sampling configuration. Metric collection reads data only after successful measurements. Failed measurements trigger reinitialization and one retry. ChangesBME280 measurement recovery
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
@mcenderdragon, Welcome to Meshtastic!Thanks for opening your first pull request. We really appreciate it. We discuss work as a team in discord, please join us in the #firmware channel. Welcome to the team 😄 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
src/modules/Telemetry/Sensor/BME280Sensor.cpp (1)
22-26: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winExtract the duplicated
setSampling(...)call into a helper.The same
setSampling(...)call, with identical arguments, appears ininitDevice(lines 22-26) and again ingetMetrics(lines 49-53). Extract it into a small helper to avoid the two call sites drifting apart over time.♻️ Proposed helper extraction
+static void configureBME280Sampling(Adafruit_BME280 &sensor) +{ + sensor.setSampling(Adafruit_BME280::MODE_FORCED, + Adafruit_BME280::SAMPLING_X1, // Temp. oversampling + Adafruit_BME280::SAMPLING_X1, // Pressure oversampling + Adafruit_BME280::SAMPLING_X1, // Humidity oversampling + Adafruit_BME280::FILTER_OFF, Adafruit_BME280::STANDBY_MS_1000); +} + bool BME280Sensor::initDevice(TwoWire *bus, ScanI2C::FoundDevice *dev) { bus->setTimeout(50); LOG_INFO("Init sensor: %s", sensorName); status = bme280.begin(dev->address.address, bus); if (!status) { return status; } - bme280.setSampling(Adafruit_BME280::MODE_FORCED, - Adafruit_BME280::SAMPLING_X1, // Temp. oversampling - Adafruit_BME280::SAMPLING_X1, // Pressure oversampling - Adafruit_BME280::SAMPLING_X1, // Humidity oversampling - Adafruit_BME280::FILTER_OFF, Adafruit_BME280::STANDBY_MS_1000); + configureBME280Sampling(bme280); initI2CSensor(); return status; }And in
getMetrics, replace the secondsetSampling(...)block withconfigureBME280Sampling(bme280);.Also applies to: 49-53
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/modules/Telemetry/Sensor/BME280Sensor.cpp` around lines 22 - 26, Extract the identical sampling configuration from initDevice and getMetrics into a shared configureBME280Sampling helper, then replace both setSampling call sites with that helper while preserving the existing arguments and behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/modules/Telemetry/Sensor/BME280Sensor.cpp`:
- Line 46: Correct the “meassurment” typo to “measurement” in both warning log
messages within the BME280 sensor measurement/reset handling, including the
message near the related line, without changing their logging behavior.
- Around line 34-71: Update BME280Sensor::getMetrics to return true only when
either the initial or recovery takeForcedMeasurement succeeds, and return false
when both attempts fail so EnvironmentTelemetryModule does not mark invalid
metrics as valid. Also add an else branch for a failed bme280.init() recovery
that logs the reinitialization failure before returning false.
- Line 15: Remove the bus->setTimeout(50) call from the BME280 sensor
initialization; do not replace it with a generic I2C timeout mechanism, and only
add platform-specific timeout handling if an appropriate API and units are
available.
---
Nitpick comments:
In `@src/modules/Telemetry/Sensor/BME280Sensor.cpp`:
- Around line 22-26: Extract the identical sampling configuration from
initDevice and getMetrics into a shared configureBME280Sampling helper, then
replace both setSampling call sites with that helper while preserving the
existing arguments and behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 9a04d9ed-4dab-4a6b-ab1b-bd1ba7d51c17
📒 Files selected for processing (1)
src/modules/Telemetry/Sensor/BME280Sensor.cpp
|
|
||
| bool BME280Sensor::initDevice(TwoWire *bus, ScanI2C::FoundDevice *dev) | ||
| { | ||
| bus->setTimeout(50); |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
Does TwoWire::setTimeout on ESP32 and nRF52 (Adafruit nRF52 core / mbed) map to Stream::setTimeout or to an I2C hardware timeout like setWireTimeout?
💡 Result:
The TwoWire::setTimeout method on ESP32 does not map to Stream::setTimeout, nor is it equivalent to setWireTimeout as used in other Arduino cores. On the ESP32 (Arduino ESP32 core), TwoWire::setTimeout is a custom, ESP32-specific API [1]. It is used to set the timeout in milliseconds for I2C transactions, which is then passed directly to the low-level i2cWrite function [2][3]. It is not related to the Stream class's setTimeout, which typically handles serial communication timing. The setWireTimeout method, which is commonly associated with the AVR and certain other cores (like Renesas) to manage I2C hardware bus lockups and timeouts, is generally not implemented in the ESP32 core under that name [4][5][6]. While the goal of the ESP32's setTimeOut is to provide a transaction-level timeout to avoid blocking, it operates independently of the setWireTimeout API found in other ecosystems [1][2]. Regarding the Adafruit nRF52 core (based on mbed), it does not natively implement setWireTimeout or the ESP32's setTimeOut as a standard feature across all boards [7][5]. The Wire library API can vary significantly between different hardware cores in the Arduino ecosystem, as there is no single, unified standard for I2C timeout configuration across all platforms [4][5]. In summary: 1. ESP32's setTimeOut is a unique, platform-specific function that controls I2C transaction duration in milliseconds [1][2]. 2. It does not interface with Stream::setTimeout [2]. 3. It is not equivalent to the setWireTimeout method found in other Arduino cores [4][5]. For cross-platform code, you cannot rely on either setWireTimeout or setTimeout to consistently provide I2C hardware timeout functionality [5].
Citations:
- 1: https://docs.espressif.com/projects/arduino-esp32/en/latest/api/i2c.html
- 2: https://github.com/espressif/arduino-esp32/blob/6cfa93f4/libraries/Wire/src/Wire.cpp
- 3: https://github.com/espressif/arduino-esp32/blob/master/libraries/Wire/src/Wire.cpp
- 4: https://forum.arduino.cc/t/no-wire-setwiretimeout-on-nano-every/1250383
- 5: https://forum.arduino.cc/t/twowire-has-no-member-named-setwiretimeout/1017499
- 6: https://github.com/arduino/ArduinoCore-avr/blob/master/libraries/Wire/src/Wire.cpp
- 7: https://forums.adafruit.com/viewtopic.php?t=122339
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Candidate file =="
fd -a 'BME280Sensor.cpp' . || true
echo "== File excerpt =="
if [ -f src/modules/Telemetry/Sensor/BME280Sensor.cpp ]; then
cat -n src/modules/Telemetry/Sensor/BME280Sensor.cpp | sed -n '1,110p'
fi
echo "== Repository Wire/TwoWire declarations =="
rg -n "class TwoWire|struct TwoWire|setTimeout|setWireTimeout|setTimeOut" -S . -g '*.h' -g '*.hpp' -g '*.cpp' | head -200
echo "== Relevant I2C bus initialization / Platform-specific APIs =="
rg -n "Wire\.(setTimeout|setWireTimeout|setTimeOut)|setTimeOut\(|setTimeout\(" . -g '*.cpp' -g '*.h' -g '*.hpp' | head -200Repository: meshtastic/firmware
Length of output: 7655
🌐 Web query:
nRF52 Adafruit TwoWire setTimeout function definition Stream.hpp inherits setTimeout
💡 Result:
In the Adafruit nRF52 Arduino core, the TwoWire class (defined in Wire.h) inherits from the Stream class [1][2]. Because the Stream class provides the setTimeout method, the TwoWire class technically inherits this function [3][4]. However, there is no specific definition or implementation of setTimeout within the TwoWire class itself in the Adafruit nRF52 library [1][5][6]. Furthermore, the TwoWire implementation for nRF52 does not utilize the Stream-based timeout functionality for its I2C operations (such as endTransmission or requestFrom) [7]. Technical findings: 1. Inheritance: TwoWire inherits from Stream, which makes setTimeout available as part of the public interface [1][2]. 2. Implementation: The TwoWire class does not override or implement its own setTimeout function [1][2]. 3. Functional Status: Users have reported that the nRF52 Wire library lacks timeout handling in its I2C communication methods, meaning that if an I2C device stalls or hangs the bus, calls to functions like endTransmission may block indefinitely because they do not implement or check for the Stream-defined timeout [7].
Citations:
- 1: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/Wire/Wire.h
- 2: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/aa0f46ce/libraries/Wire/Wire.h
- 3: https://nola.coxlab.kr/classStream.html
- 4: https://download.coxlab.kr/doc/classStream.html
- 5: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/Wire/Wire_nRF52.cpp
- 6: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/aa0f46ce/libraries/Wire/Wire_nRF52.cpp
- 7: I2C communication between NRF52832 hangs adafruit/Adafruit_nRF52_Arduino#771
🌐 Web query:
Adafruit nRF52 TwoWire stream setTimeout I2C requestFrom timeout
💡 Result:
In the Adafruit nRF52 Arduino core, the TwoWire implementation does not support a software-based timeout mechanism for I2C transactions [1]. Unlike some other Arduino cores (such as AVR) that implement setWireTimeout to recover from bus hangs [2][3][4], the Adafruit nRF52 Wire library lacks this functionality [1][5][6]. Technical details: 1. Blocking Behavior: The TwoWire::requestFrom and endTransmission functions in the nRF52 core are blocking [1][5][6]. They utilize while loops to poll hardware event registers (e.g., EVENTS_RXSTARTED, EVENTS_LASTRX, EVENTS_STOPPED) [5][6]. 2. Lack of Timeout: If an I2C device fails to respond, NACKs, or holds the bus in a way that prevents these hardware events from triggering, the code will remain stuck in these while loops indefinitely [1][7]. 3. No setWireTimeout: The setWireTimeout function available in other Arduino cores is not part of the standard Adafruit nRF52 Wire library API [8][2]. Users experiencing hangs due to unresponsive I2C devices will find that the system does not automatically recover [1]. Workarounds and Recommendations: * Hardware Reliability: Since software recovery is unavailable, ensure physical I2C bus integrity. This includes using correct pull-up resistors and addressing signal noise, which are common causes of hangs on the nRF52 [1]. * External Watchdog: Using the internal nRF52 Watchdog Timer (WDT) is the most robust way to recover the system if an I2C hang occurs. You can configure the WDT to reset the microcontroller if the main loop stops responding due to an I2C block. * Custom Implementation: While advanced users could theoretically attempt to modify Wire_nRF52.cpp to add timeout checks based on a timer or micros [1], this requires custom firmware builds and is not a standard supported feature.
Citations:
- 1: I2C communication between NRF52832 hangs adafruit/Adafruit_nRF52_Arduino#771
- 2: https://docs.arduino.cc/language-reference/en/functions/communication/wire/setWireTimeout
- 3: https://github.com/arduino/ArduinoCore-avr/blob/master/libraries/Wire/src/Wire.cpp
- 4: https://github.com/arduino/ArduinoCore-avr/blob/6d0078318c0430b2f04a8c150d894f008ea0d317/libraries/Wire/src/utility/twi.c
- 5: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/Wire/Wire_nRF52.cpp
- 6: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/aa0f46ce/libraries/Wire/Wire_nRF52.cpp
- 7: https://forum.arduino.cc/t/question-about-twi-and-wire-requestfrom-hanging/429052
- 8: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/Wire/Wire.h
🌐 Web query:
mbed Wire TwoWire setTimeout nRF52
💡 Result:
The class TwoWire does not consistently implement a universal setWireTimeout method across all Mbed-enabled or Arduino-based nRF52 platforms [1][2]. In the context of the Mbed OS nRF52 HAL (Hardware Abstraction Layer), timeout management for I2C (TWI) operations is handled internally by the driver rather than through a public TwoWire method [3]. Historically, issues with I2C "hanging" on nRF52 due to clock stretching or bus errors have been managed by modifying internal timeout values within the driver's C source code (e.g., i2c_api.c), often involving the use of microsecond tickers to monitor transaction duration [4][5][3][6]. If you are using the Arduino framework on an nRF52 (such as the Adafruit nRF52 board support package), the Wire library may lack a setWireTimeout() method [2], which is commonly found in other architectures like AVR [7] or ESP32 [8]. Because implementation varies by the specific board support package (BSP) and Mbed OS version, you should check the following: 1. Check for library-specific methods: Some variants of the Wire library may implement setTimeout(ms) [8], but this is not guaranteed for all nRF52 cores [1][2]. 2. Consult the underlying HAL: If your application hangs during I2C, it is often due to the driver entering an infinite loop while waiting for hardware events (like STOP or RX/TX) [2]. On Mbed-based platforms, ensure you are using a recent version of the OS, as many I2C driver instabilities regarding timeouts and clock stretching have been addressed in later releases [6][9]. 3. Manual Timeout: If the library lacks an API to set a timeout, you may need to implement a "watchdog" approach or use a non-blocking I2C wrapper if available, or verify your hardware pull-up resistors to prevent bus lockup conditions [2]. In summary, there is no standardized setWireTimeout API for TwoWire on nRF52; reliance on driver-level internal timeouts or higher-level application logic is generally required [3][2].
Citations:
- 1: https://forum.arduino.cc/t/no-wire-setwiretimeout-on-nano-every/1250383
- 2: I2C communication between NRF52832 hangs adafruit/Adafruit_nRF52_Arduino#771
- 3: https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/i2c_api.c
- 4: nRFx: Use us ticker for I2C timeout ARMmbed/mbed-os#5187
- 5: Nordic RF52 I2C driver times out too soon for clock-stretching slaves ARMmbed/mbed-os#4826
- 6: nRF52832 Sluggish App - I2C Timeout? ARMmbed/mbed-os#6207
- 7: https://github.com/arduino/ArduinoCore-avr/blob/24e6edd475c287cdafee0a4db2eb98927ce3cf58/libraries/Wire/src/Wire.cpp
- 8: https://github.com/espressif/arduino-esp32/blob/master/libraries/Wire/src/Wire.h
- 9: nrf52 - fix i2c/twi driver ARMmbed/mbed-os#11676
🌐 Web query:
Adafruit nRF52 TwoWire setTimeout function definition Stream.hpp inherits setTimeout
💡 Result:
In the Adafruit nRF52 Arduino core, the TwoWire class inherits from the Arduino Stream class [1][2]. The Stream class provides the setTimeout(unsigned long timeout) method [3][4][5], which sets the maximum time, in milliseconds, that the stream will wait for data [6]. However, for the TwoWire class in the Adafruit nRF52 implementation, the setTimeout method from the Stream class is intended for stream-based reading operations (e.g., read, peek) [3][6]. It does not provide I2C bus timeout functionality for methods like endTransmission or requestFrom [7]. Because the TwoWire implementation in this core lacks specific I2C timeout mechanisms, these I2C functions can hang if the bus or target device experiences issues [7]. To clarify: 1. Inheritance: TwoWire inherits from Stream [1][2], so it technically has access to the setTimeout function inherited from the base class [3][6]. 2. Functionality: This setTimeout function affects operations that use the stream-based read/peek logic [6] and does not control the low-level TWI/I2C communication timing [7]. 3. I2C Timeouts: The Adafruit nRF52 TwoWire class does not implement a setWireTimeout function or similar I2C-specific timeout control, which is a known limitation when compared to some other Arduino cores [7][8].
Citations:
- 1: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/Wire/Wire.h
- 2: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/aa0f46ce/libraries/Wire/Wire.h
- 3: https://download.coxlab.kr/doc/classStream.html
- 4: https://nola.coxlab.kr/classStream.html
- 5: https://links2004.github.io/Arduino/d1/d51/class_stream.html
- 6: https://documentation.help/Arduino-W60X/class_two_wire.html
- 7: I2C communication between NRF52832 hangs adafruit/Adafruit_nRF52_Arduino#771
- 8: https://forum.arduino.cc/t/twowire-has-no-member-named-setwiretimeout/1017499
Remove the non-portable I2C timeout call.
bus->setTimeout(50) is not a portable I2C hang-protection call. On the nRF54L15 platform in this repository, TwoWire::setTimeout() is an empty stub, so this call does nothing. On core variants where it is inherited from Stream, it affects stream-read helpers instead of requestFrom()/endTransmission(). If I2C timeout behavior is required, gate it behind platform-specific APIs and use the correct timeout type/units for each implementation.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/modules/Telemetry/Sensor/BME280Sensor.cpp` at line 15, Remove the
bus->setTimeout(50) call from the BME280 sensor initialization; do not replace
it with a generic I2C timeout mechanism, and only add platform-specific timeout
handling if an appropriate API and units are available.
|
@coderabbitai please check if now all is resolved. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
printf '%s\n' '--- Changed files and diff ---'
git diff --find-renames origin/main...HEAD -- src/modules/Telemetry/Sensor/BME280Sensor.cpp
printf '%s\n' '--- BME280Sensor.cpp outline ---'
ast-grep outline src/modules/Telemetry/Sensor/BME280Sensor.cpp --items all
printf '%s\n' '--- Pull request review comments ---'
gh api repos/meshtastic/firmware/pulls/11302/comments \
--paginate \
--jq '.[] | {id, user: .user.login, path, line, body, created_at, in_reply_to_id}'Length of output: 886 🏁 Script executed: #!/bin/bash
set -euo pipefail
printf '%s\n' '--- Pull request metadata ---'
gh pr view 11302 --repo meshtastic/firmware \
--json baseRefName,headRefName,commits,reviewThreads \
--jq '{baseRefName, headRefName, commits: [.commits[] | {oid, messageHeadline}], reviewThreads: [.reviewThreads[] | {isResolved, comments: [.comments[] | {author: .author.login, path, line, body}]}]}'
printf '%s\n' '--- Current BME280Sensor.cpp ---'
ast-grep outline src/modules/Telemetry/Sensor/BME280Sensor.cpp --items all
nl -ba src/modules/Telemetry/Sensor/BME280Sensor.cpp | sed -n '1,280p'
printf '%s\n' '--- GitHub review comments ---'
gh api repos/meshtastic/firmware/pulls/11302/comments \
--paginate \
--jq '.[] | {id, user: .user.login, path, line, body, created_at, in_reply_to_id}'
printf '%s\n' '--- GitHub PR diff ---'
gh api -H 'Accept: application/vnd.github.diff' repos/meshtastic/firmware/pulls/11302Length of output: 1921 🏁 Script executed: #!/bin/bash
set -u
printf '%s\n' '--- Pull request metadata ---'
gh pr view 11302 --repo meshtastic/firmware \
--json baseRefName,headRefName,commits,reviewDecision,mergeable \
--jq '{baseRefName, headRefName, reviewDecision, mergeable, commits: [.commits[] | {oid, messageHeadline}]}' \
|| true
printf '%s\n' '--- BME280Sensor.cpp structure and content ---'
ast-grep outline src/modules/Telemetry/Sensor/BME280Sensor.cpp --items all || true
nl -ba src/modules/Telemetry/Sensor/BME280Sensor.cpp | sed -n '1,320p' || true
printf '%s\n' '--- Pull request review comments ---'
gh api repos/meshtastic/firmware/pulls/11302/comments \
--paginate \
--jq '.[] | {id, user: .user.login, path, line, body, created_at, in_reply_to_id}' \
|| true
printf '%s\n' '--- Pull request review threads ---'
gh api graphql \
-F owner='meshtastic' \
-F name='firmware' \
-F number=11302 \
-f query='
query($owner: String!, $name: String!, $number: Int!) {
repository(owner: $owner, name: $name) {
pullRequest(number: $number) {
reviewThreads(first: 100) {
nodes {
isResolved
path
line
comments(first: 20) {
nodes {
author { login }
body
createdAt
}
}
}
}
}
}
}' \
--jq '.data.repository.pullRequest.reviewThreads.nodes' \
|| true
printf '%s\n' '--- Pull request diff ---'
gh api -H 'Accept: application/vnd.github.diff' repos/meshtastic/firmware/pulls/11302 \
|| trueLength of output: 59224
Resolved:
Still unresolved:
Please remove this generic timeout call unless the code uses a supported, platform-specific I2C timeout API. You are interacting with an AI system. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
echo '=== Changed files and diff ==='
git diff --find-renames origin/"$(git remote show origin | sed -n '/HEAD branch/s/.*: //p')"...HEAD -- src/modules/Telemetry/Sensor/BME280Sensor.cpp || true
echo '=== BME280Sensor.cpp outline ==='
ast-grep outline src/modules/Telemetry/Sensor/BME280Sensor.cpp --items all --view expanded || true
echo '=== BME280Sensor.cpp ==='
cat -n src/modules/Telemetry/Sensor/BME280Sensor.cpp
echo '=== Declaration candidates ==='
fd -i 'BME280Sensor*' . -t f -x sh -c 'echo "--- $1"; ast-grep outline "$1" --items all --view expanded; cat -n "$1"' sh {} || true
echo '=== Related measurement/retry/timeout usages and tests ==='
rg -n -i -C 3 \
'(BME280Sensor|performReading|takeForcedMeasurement|setTimeout|Wire\.setTimeOut|measurement.*success|BME280)' \
-g '!src/modules/Telemetry/Sensor/BME280Sensor.cpp' \
-g '*test*' -g '*Test*' -g '*.cpp' -g '*.h' -g '*.hpp' .Length of output: 35139 🏁 Script executed: #!/bin/bash
set -euo pipefail
echo '=== Pull request changed-file summary ==='
git diff --stat "$(git merge-base origin/$(git remote show origin | sed -n '/HEAD branch/s/.*: //p') HEAD)" HEAD
git diff --name-status "$(git merge-base origin/$(git remote show origin | sed -n '/HEAD branch/s/.*: //p') HEAD)" HEAD
echo '=== I2C class declarations and timeout methods ==='
rg -n -i -C 5 \
'(class\s+TwoWire\b|struct\s+TwoWire\b|setTime(out|Out)\s*\(|setTime(out|Out)\s*\()' \
src variants -g '*.h' -g '*.hpp' -g '*.cpp' || true
echo '=== Platform configuration relevant to nRF and I2C ==='
fd -t f -e h -e hpp -e cpp -e ini . src/platform variants \
| xargs -r rg -n -i -C 3 '(TwoWire|setTime(out|Out)|Wire\.|i2c.*timeout|nrf54)' || true
echo '=== Test directories and BME280-related test references ==='
fd -t d -i 'test*' . -E .git -E .pio -E build || true
rg -n -i -C 3 'BME280(Sensor)?|takeForcedMeasurement' \
-g '*test*' -g '*Test*' -g '*.cpp' -g '*.h' -g '*.hpp' . || trueLength of output: 130197
The measurement failure handling is otherwise improved. The code retries after a failed forced measurement and sets metric presence flags only after a successful read. Please use an I2C timeout API that is supported on all target platforms, or add an equivalent You are interacting with an AI system. |
|
Update: T114 did hang mid blink, and no different log output aka it hangs durign the takeForcedMeassurement Call. Only a hardware watchdog can probaply fix this. |
3 participants
See issue #11301
I will test around if this fixes that issue, overall I think testing if the meassurment is successfull is needed. Also will need to test if millis() even works on the nRF or if the timeout never fires.
🤝 Attestations
Summary by CodeRabbit